CMake: MCUboot: fix image hex address in RAM Load mode #97413
Conversation
zephyrbot
added
area: Boards/SoCs
platform: STM32
zephyrbot
requested review from
57300,
FRASTM,
GeorgeCGV,
djiatsaf-st,
erwango,
etienne-lms,
gautierg-st,
jeremybettis,
marwaiehm-st,
mathieuchopstm,
nashif,
nordicjm and
tejlmand
|
My first point would be that you are missing a |
|
Saw you need to manually specify it, so it is not default. Anyhow, this fixes it with the ranges property, otherwise you are declaring that the flash partitions start at 0x0 in dts, which is wrong: |
@nordicjm STM32N6 is a specific kind of STM32: there is no internal flash. In default mode, the BootROM (internal and non updatable bootloader) will load the binary (called First Stage Boot Loader) from ext flash (at a specific location) to RAM, which will then execute in |
cmake/mcuboot.cmake
Outdated
| endif() | ||
| set(imgtool_args_alt_slot ${imgtool_args} --hex-addr ${slot1_partition_address}) | ||
| set(imgtool_args ${imgtool_args} --hex-addr ${slot0_partition_address}) | ||
| math(EXPR SLOT0_PARTITION_ADDRESS "${CONFIG_FLASH_BASE_ADDRESS} + ${slot0_partition_address}") |
There was a problem hiding this comment.
I'm implementing a CMake function in cmake.extensions, to replace dt_reg_addr above, that will give the absolute address of the slot partition, similar to the macro
JarmouniA
force-pushed
the
fix_mcuboot_ramload_img_hexaddr
branch
2 times, most recently
from
cf50563 to
c6ca4e9
Compare
Introduce a new dt_fixed_partition_addr() function that returns the absolute address of a fixed partition, meaning the sum of the base address of the containing grand-parent node and the partition's offset. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>
In RAM LOAD mode, the app slot addr is taken as the hex-addr passed to imgtool, which is only correct if the grand-parent node's (usually the flash node) absolute address is actually 0, because the addresses of all the flash fixed-partitions in-tree are relative to their grand-parent node's address. Hence, use the newly added dt_fixed_partition_addr() function to get the absolute address of app slots partitions. Signed-off-by: Abderrahmane JARMOUNI <[email protected]>
JarmouniA
force-pushed
the
fix_mcuboot_ramload_img_hexaddr
branch
from
c6ca4e9 to
b8d5d47
Compare
|
Removed N6 modifs. |
| dt_fixed_partition_addr(slot0_partition_address PATH ${slot0_partition}) | ||
| dt_nodelabel(slot1_partition NODELABEL "slot1_partition" REQUIRED) | ||
| dt_reg_addr(slot1_partition_address PATH ${slot1_partition}) | ||
| dt_fixed_partition_addr(slot1_partition_address PATH ${slot1_partition}) |
There was a problem hiding this comment.
I present a complete failure showcase for this:
diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..fd51c151379 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -23,15 +23,24 @@
reg = <0x00000000 0x0000C000>;
};
- slot0_partition: partition@c000 {
+ slot_partitions: partition@c000 {
+ compatible = "fixed-subpartitions";
+ label = "image-0";
+ reg = <0x0000c000 0xec000>;
+ ranges = <0x0 0xc000 0xec000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ slot0_partition: partition@0 {
label = "image-0";
- reg = <0x0000C000 0x00076000>;
+ reg = <0x00000000 0x00076000>;
};
- slot1_partition: partition@82000 {
+ slot1_partition: partition@76000 {
label = "image-1";
- reg = <0x00082000 0x00076000>;
+ reg = <0x00076000 0x00076000>;
};
+};
/*
* The flash starting at 0x000f8000 and ending at
Build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 with -DFILE_SUFFIX="ram_load" and observe the huge error. The issue on your board has the correct solution described on #97413 (comment) you are not setting ranges and then declaring a child node has address 0, this means it starts at physical address 0x0, your DTS file is wrong
There was a problem hiding this comment.
+ ranges = <0x0 0x70000000 0x1000000>;
partitions {
Ranges here has no effect on the individual partitions absolute address (seen in devicetree_generated.h), because I think the immediate childnode is partitions, not the the partition@x itself. Adding ranges = <.... inside partitions node gives build errors.
There was a problem hiding this comment.
you need both ranges, the one with addresses on the outside one and one without parameters on the partitions node
There was a problem hiding this comment.
I'm testing this on the STM32H750B-DK, so can you please give me your exact suggestion based on what is in https://github.com/JarmouniA/zephyr_dev/blob/bcc40a2916d28f1858a94bd5f50903ff88cc7cee/boards/st/stm32h750b_dk/stm32h750b_dk_stm32h750xx_ext_flash_app.dts#L37
and https://github.com/JarmouniA/zephyr_dev/blob/bcc40a2916d28f1858a94bd5f50903ff88cc7cee/boards/st/stm32h750b_dk/stm32h750b_dk-common.dtsi#L176
There was a problem hiding this comment.
Also, if ranges takes care of this, why do DT_FIXED_PARTITION_ADDR and DT_FIXED_SUBPARTITION_ADDR macros exist!?
6 participants
In MCUBoot RAM LOAD mode, the app slot addr is taken as the hex-addr passed to imgtool to create slot0 & 1 images, which is only correct if the grand-parent node's (usually the flash node) absolute address is actually 0, because the addresses of all the flash fixed-partitions in-tree are relative to their grand-parent node's address.
Hence, use the newly added
dt_fixed_partition_addr()CMake function to get the absolute address of app slots partitions.dt_fixed_partition_addr()is equivalent to the MACROzephyr/include/zephyr/devicetree/fixed-partitions.h
Line 133 in 8a72d77